Communications networks are commonplace today, providing communication services between users. Some of these networks are adapted to handle packet data, where individual data packets or units are used for transferring the data in the communication between two or more signaling points, such as two terminals or other nodes in the communication system. Packet data networks may be roughly divided into two categories: connection-oriented and connectionless.
In connection-oriented networks, also known as circuit switched networks, a virtual-circuit is set up between the source and destination node using appropriate call set-up and admission control techniques. This circuit, which may span several intermediate nodes in the network, remains open for the duration of the communication, with all data packets relating to the communication being transmitted over the circuit. The effect is analogous to a voice call on a standard phone line such as over a public switched telephone network (PSTN). An example of a connection-oriented network is a X.25 network used for transmitting data packets.
In connection-less networks, also known as packet switched networks, no predetermined fixed circuit is set up between the source and destination nodes for the transfer of the data packets in the communication. Instead, data packets are routed on a ‘hop-by-hop’ basis from the source node to the destination node via intermediate nodes. At each intermediate node in receipt of a data packet, the header of the data packet is examined and the data packet then routed to another node that is closer to the destination node. This process is repeated at each intermediate node until the data packet reaches the destination node. An example of a connection-less network is the Internet or an Internet Protocol (IP) network, which operates under TCP/IP (Transport Control Protocol/Internet Protocol). It should be noted that the terms ‘node’ and ‘router’ may be used interchangeably in this description as references to an IP network are made, wherein routers act as nodes that route data.
In both types of network, a sequence of related data packets that typically makes up the data in a communication between two terminals is often called a data flow or data stream.
Data may become congested at network nodes if the data is received at a node at a rate greater than the maximum data throughput rate at that node. Typically, congestion occurs at a node when the node has a lower data throughput rate than the node that precedes it in the same direction or flow. Similarly, congestion occurs when a node receives data from a plurality of data sources and the sum of the input data rates exceeds the data throughput of the node.
Many IP networks use a so-called “best effort” model where no guarantees about packet loss or transfer delay are made. Packet loss generally occurs at the buffers of an IP router. In the best effort model, the output buffers of an IP router are typically a first-in first-out (FIFO) type of queue. If a buffer becomes full then new data packets are simply dropped regardless of their origin or the flow that they belong to.
Methods have been developed to manage networks so that the forwarding service provided by the network to packets, particularly data packets in a communication that is deemed to be of particular importance by the user, is predictable and engineerable. Managing of network resources to produce engineered performance according to requirement of different services may include Quality of Service (QoS).
From the network point of view, QoS can be viewed as a set of parameters that provide an indication of the quality of service that is expected from the network at any given time. For example, if a data flow is assigned a set of QoS parameters defining a packet loss rate and an end-to-end delivery delay for the data packets in the flow, the network nodes handling the routing of the data packets should prioritise the routing of the node so that the QoS defined is maintained for the data flow.
The Internet Engineering Task Force (IETF) has defined a ‘flow label’ field for use in IP version 6, (IPv6). The flow label is a 20-bit field for use in the header of an IPv6 data packet. It has been envisaged that the flow label be used to identify a traffic flow to which a data packet belongs or to give a data packet some flow-specific treatment. The nodes in the IP network can use information stored within the each node to process the data in a flow in accordance with the flow label. Therefore, each node optimally manages the data flows.
The IETF has also developed a standard for the QoS approach called Differentiated Services (DiffServ). In the DiffServ model data packets have six bits in the packet header called a DiffServ Code Point (DSCP), which indicates how an IP router should handle a data packet. A DSCP is marked on a field that can be found in both IPv4 and IPv6 headers. In IPv6 headers, the DSCP is marked in the 8-bit traffic class field. The DSCP corresponds to a Per-Hop Behaviour (PHB) for a packet, giving an indication of the priority of the data packet. The PHB is allocated to the packets belonging to a flow based on the QoS or a service level requirement of an application. Data flows requiring a high QoS will be marked with a suitable DSCP to reflect this. Differently marked packets may receive a different priority in queuing and/or scheduling of nodes. DSCP is used as a token of the PHB assigned to the packet at the edge of the DiffServ domain. In DiffServ, packets are prioritised with respect to forwarding and dropping based upon the DSCPs marked in the packet headers. Thus it is possible to start to discard, for example, low priority IP packets first before the buffers of an IP router are completely full and only discard higher priority packets when congestion becomes worse. This technique leaves buffer space for the higher priority packets, which will not see any congestion at all.
Flow labels are used in conjunction with a source identifier or source address and destination identifier or destination address to form a triplet that enables efficient flow classification. All data packets in a given data flow are marked with the flow label assigned to that data flow. The triplet of each data flow uniquely identifies the flow and distinguishes it from other flows. Practical implementation of this requires support from the sending IP host. Thus, where a traffic class adopting for example DSCP only allows for identification of a traffic aggregate (PHB), such as a QoS, properly implemented flow label allows identification of individual flows uniquely using only data in the basic IP header, namely the flow label, source address and destination address. Without the flow label, information identifying the flow would need to be extracted from higher-layer headers, e.g. TCP (transport control protocol) and UDP (user datagram protocol) headers. When cryptographic methods are used, such as IPSec (IP security protocol), higher-layer headers may not be available in plaintext, thereby removing the ability to identify the flow using the higher-layer headers.
Furthermore, a DSCP is typically assigned per transport domain (also known as the Autonomous Domain, AD). The definition of a DSCP can differ across ADs, and thus different DSCP markings could be used along the end-to-end path in different domains for any given flow. As a result, by using DiffServ and DSCP alone there is no record of the original end-to-end QoS assigned to the flow in question. The flow label can be used for this purpose. However, the use of the 20-bits of the flow label has not yet been standardized, and currently there are no plans to do so.
One way to use the flow label in recording end-to-end QoS requirements is to use extra-data plane mechanisms such as signaling of the state associated with flow label across domain boundaries. Alternatively, the QoS requirement for the flow could be marked directly into the flow label. Such marking could be based on classification for delay and packet loss, for example. In another example, a DSCP could be marked to the flow label, reflecting the original PHB allocated to the flow.
The use of flow labels forms an important part of communications in IP networks. A problematic area in their use is termed ‘theft-of-service’, which could affect the use of a flow label for QoS. Theft-of-service could occur when a data flow is marked with a better QoS class onto the flow label than that to which it is entitled. The result is that the packet data of the data flow may not be processed in the manner allowed to the sender by the network operator. Thus there is a need to authenticate the flow label marking against the QoS or service level allocated to the user, such as a DSCP, to ensure that the flow label has not been tampered with.
It is the aim of embodiments of the present invention to at least partly mitigate the above-mentioned problems.